Amiga Collections: Taifun/Taifun 095 (1989-05-15)(Ossowski, Stefan)(DE)(PD).zip/Taifun 095 (1989-05-15)(Ossowski, Stefan)(DE)(PD).adf/KeyKlick/Keyclick.doc

Text File | 1989-03-31 | 5KB | 145 lines

                           Keyclick version 1.1


     One thing I always missed about the Amiga was an audio click when the

keys were pressed.  While the Amiga keyboard has the best feel of any I've

typed on, it doesn't have a form of audio feedback, which aids in

touch-typing.  Thanks to the multitasking operating system however, the

addition of such a feature is relatively painless, both from a user's and a

programmer's standpoint.

     Upon running the program, a window will be presented which contains

two gadgets.  The slider is used for adjusting the volume of the click.  The

toggle switch can be "pressed" to turn the sound on or off.  After the

program is up and running, an audio click will be produced at each press of

a key on the keyboard or a mouse button.  You cannot run more than one key

clicker at a time; the second clicker that you run will indicate that a

key-clicker is already active in the system.  Simply close the window to

end the program.  That's about all you have to know as a user.

     For you programmers out there...  This program demonstrates custom

input handlers and effectively sharing the complicated audio device; two

concepts that can be put to great use.

     The center of activity revolves around a custom input handler, which

simply signals the waiting task when a key or mouse button event arrives in

the input stream.  Once the task is awakened, it sends a command to the

audio device to initiate the click and goes back to sleep. Therefore, this

program only uses a significant amount of processor time when a key or

mouse button is actually pressed.

     I had the program set its own priority to fourty (this can be changed

by assigning a different value to TASK_PRIORITY, defined at the beginning

of the program) for better response.  At lower task priority values, the

program tended to be sluggish on occasion (especially in a busy system).

The input handler priority (defined by HANDLER_PRIORITY) is set at

fifty-one.  This causes events from the input stream to be intercepted

before Intuition gets ahold of them.  This is desirable because Intuition

"swallows" some of the events.  That is, it removes some of them from the

input stream, preventing the custom input handler from notifying the

clicker task.

     At each stroke of a key, an audio channel is allocated, a sound

request is issued to the audio device, and the channel previously allocated

is freed.  All of this takes place within the click() routine.  After a

channel is allocated (via a call to get_audio_channel()), the io_Unit

parameter is checked to see if an allocation actually succeeded.  A zero in

this parameter indicates that no channel could be allocated.  If this is

the case, the click() routine returns immediately without attempting to ask

the audio device to make a click sound.  Any other value in io_Unit denotes

which channel has been allocated for use.  The IOAudio structure is

prepared for a CMD_WRITE to issue a sound request to the audio device, and

is executed with a call to BeginIO().  A WaitIO() call is immediately

issued after the BeginIO() so the program waits until completion of the

write request.  This is needed to delay freeing the channel until the click

sound is completed playing (after WaitIO() returns, a call to

free_audio_channel() frees the previously allocated audio channel).

     An alternate method of audio manipulation would be to allocate an

audio channel at the beginning of the program and set it to the highest

possible priority (127) to prevent it from being stolen by other tasks

requiring audio channels.  However, this method does not take full

advantage of the audio device's sophistication; it must be remembered that

in a multitasking environment you have to share resources.  Allocating and

"holding on" to an audio channel is very uncooperative (and selfish!).

     The in-line assembly language at the end of the C source code is an

input handler interface, which is required for the system to "communicate"

with the custom input handler.  In other words, it copies the appropriate

system registers (A0 and A1) to the stack to conform with the input handler

calling convention.  This is absolutely essential if the system is to work

correctly with the custom input handler.

     I would like to hear your comments on this program.  Feel free to

E-Mail me on GEnie (MMD) or Delphi (MOCKO).


     Note- a simplified version of this program (V1.0) can be found in the
November 1988 issue of Amazing Computing.  The program as it appears in
print statically allocates an audio channel, therefore preventing any other
task in the system from allocating (stealing) it.  This version of the
program dynamically allocates an audio channel at a priority of -90 each
time a key is pressed, and works well with other tasks using the audio
device (at least with my experiences).  This version also adds a toggle
switch to enable the user to prevent the program from clicking if so
desired.  If any problems are encountered in using this program, I'd like
to know so I can upload updated versions. Thank you. -Mike